docs: add provisional GEP for extending TLS Validation in BackendTLSPolicy #4153
Conversation
k8s-ci-robot
added
release-note-none
k8s-ci-robot
added
do-not-merge/hold
|
/cc @rikatz |
|
/assign |
geps/gep-4152/index.md
Outdated
|
|
||
| The current `BackendTLSPolicy` follows a secure-by-default approach that requires users to provide a trusted CA certificate bundle or rely on the system’s default certificate store (which typically includes root CAs) to validate backend server certificates. However, real-world deployments include cases where strict certificate validation may not be possible or practical, e.g., Development and testing environments that use self-signed certificates generated dynamically at runtime. | ||
|
|
||
| In such scenarios, users may need the flexibility to disable certificate verification, or to use certificate pinning. Certificate pinning offers a safer and more controlled alternative, instead of bypassing TLS validation, the gateway verifies that the backend’s certificate matches a known fingerprint or public key hash. This preserves the confidentiality and integrity guarantees of TLS while removing the operational overhead of managing full certificate chains or trusted CA bundles. |
There was a problem hiding this comment.
just a question: cert pinning CAN be combined with BackendTLSPolicy to also offer a safer approach than the current as well today, right? (like I accept just from this CA + this hash)
Do you think it is worth mentioning it here, or do we want a different GEP for certificate pinning explaining what it will be used for? (eg.: as you have here: https://github.com/kubernetes-sigs/gateway-api/pull/4079/files)
I think probably it is fine to keep separated what matters on client certificate from what matters on backend/server certificate.
Maybe to avoid confusion, call it Extending TLS Validation in BackendTLSPolicy as the validation of the CA and SAN already exists on it.
There was a problem hiding this comment.
Certificate pinning could technically be combined with CA validation. IMO, that approach doesn’t make much sense as I can’t think of a real-world use case where you’d want to both trust a specific certificate (or its fingerprint) and also require it to be signed by a particular CA. When you decide to trust a certificate’s hash, you’re already asserting its authenticity, so checking the CA that signed it adds little value.
I also considered creating a separate GEP for the certificate pinning feature, but it would be unfortunate if it remained stuck in the Provisional phase. Since many users are primarily asking for the ability to skip TLS validation, I’d prefer to include certificate pinning as part of the same proposal. This way, we can provide a more secure alternative to completely disabling certificate validation, especially for environments using self-signed certificates.
There was a problem hiding this comment.
right, my point is that certificate pinning is just an additional field as
gateway-api/apis/v1/backendtlspolicy_types.go
Line 219 in 1cf7222
- I trust the CA
- I don't have CRL (yet)
- I want to be sure that the cert I am using is well known (eg.: if the old one is revoked, and you have a new one with a new hash, you can enforce that new one)
Not a blocker, mostly thinking that the pinning being used as an aggregated validation mechanism could also be considered
…licy Signed-off-by: Norwin Schnyder <[email protected]>
snorwin
changed the title
Signed-off-by: Norwin Schnyder <[email protected]>
|
/lgtm |
k8s-ci-robot
added
the
lgtm
k8s-ci-robot
added
the
approved
Signed-off-by: Norwin Schnyder <[email protected]>
k8s-ci-robot
removed
the
lgtm
k8s-ci-robot
removed
the
do-not-merge/hold
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: shaneutt, snorwin The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
geps/gep-4152/index.md
Outdated
| * As a gateway operator, I want to control whether skipping TLS verification is | ||
| permitted for specific Gateways. |
There was a problem hiding this comment.
I like having this as a user story, it would address my concern from #3761 (comment) and feels aligned with the consumer override approach proposed by @howardjohn in #3876
|
This feels like a good initial direction to address the use cases described in #3761 /lgtm |
k8s-ci-robot
added
the
lgtm
What type of PR is this?
/kind gep
What this PR does / why we need it:
This proposes a first provisional GEP (what/why/who) for enabling flexible TLS validation in
BackendTLSPolicy, allowing options such as skip verification and certificate pinning to better support scenarios as described in #3761.Which issue(s) this PR fixes:
This supports, but does not resolve #4152.
Does this PR introduce a user-facing change?: